New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weekly packages not implemented yet #2463

Closed
hermunn opened this Issue Oct 16, 2017 · 20 comments

Comments

Projects
None yet
6 participants
@hermunn
Contributor

hermunn commented Oct 16, 2017

During a discussion about releases and helping users run recent software, publishing weekly packages was suggested and agreed upon.

This is not implemented yet, and my intention is to use this issue to discuss a possible implementation:

  • During the Monday bugwash, the varnish core developers discuss if the current master should be released as a weekly package.
  • If agreement is reached, the gitref will be tagged with an annotated tag on the form weekly-2017-10-16 and a message "Releasing weekly package from trunk ". (git tag -a -m "Releasing weekly package from trunk 2017-10-16" weekly-2017-10-16 and then, after checking that the tag looks sane, git push origin weekly-2017-10-16)
  • A script managed by Varnish Software monitors GitHub for such tags, builds the packages (for the supported platforms), tests for installation problems and finally publishes to a public repository on Packagecloud.

Comments and input are welcome.

@Dridi Dridi added the a=bugwash label Oct 16, 2017

@bsdphk

This comment has been minimized.

Show comment
Hide comment
@bsdphk

bsdphk Oct 16, 2017

Contributor

Looks good to me.

Contributor

bsdphk commented Oct 16, 2017

Looks good to me.

@fgsch

This comment has been minimized.

Show comment
Hide comment
@fgsch

fgsch Oct 16, 2017

Member

I'm a bit worried about the amount of tags this will create.

Do we really need to push it? Can all this be done internally without actually pushing the tag?
After all the revision is embedded into varnish already so it'd be relatively easy to reproduce.

Member

fgsch commented Oct 16, 2017

I'm a bit worried about the amount of tags this will create.

Do we really need to push it? Can all this be done internally without actually pushing the tag?
After all the revision is embedded into varnish already so it'd be relatively easy to reproduce.

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 16, 2017

Member

@fgsch this is why I invited @hermunn to include me in the discussions, I'd like to avoid that too.

Member

Dridi commented Oct 16, 2017

@fgsch this is why I invited @hermunn to include me in the discussions, I'd like to avoid that too.

@hermunn

This comment has been minimized.

Show comment
Hide comment
@hermunn

hermunn Oct 16, 2017

Contributor

Ok, this is a valid point, but I really like the convenience that public tags offer.

The main point of the plan was that a script periodically pulls from the repo and reacts to tags. I guess we could change this to pushing the tag to a private repo (not GitHub), but then we have to manage who can push this tags and trigger a build. Does that sound good to you, @fgsch and @Dridi? Any other concrete suggestions?

Contributor

hermunn commented Oct 16, 2017

Ok, this is a valid point, but I really like the convenience that public tags offer.

The main point of the plan was that a script periodically pulls from the repo and reacts to tags. I guess we could change this to pushing the tag to a private repo (not GitHub), but then we have to manage who can push this tags and trigger a build. Does that sound good to you, @fgsch and @Dridi? Any other concrete suggestions?

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 16, 2017

Member

Yes, one tag called weekly, since we are planning to pick specific commits for the weekly builds:

  • push tag removal
  • tag new blessed commit
  • push new tag

We can even script this easily.

On the builder side:

  • if no tag (small window unless something happens) poll again later
  • if same tag as last build, poll again later
  • build
Member

Dridi commented Oct 16, 2017

Yes, one tag called weekly, since we are planning to pick specific commits for the weekly builds:

  • push tag removal
  • tag new blessed commit
  • push new tag

We can even script this easily.

On the builder side:

  • if no tag (small window unless something happens) poll again later
  • if same tag as last build, poll again later
  • build

@Dridi Dridi removed the a=bugwash label Oct 16, 2017

@hermunn

This comment has been minimized.

Show comment
Hide comment
@hermunn

hermunn Oct 17, 2017

Contributor

I am fine with updating and force pushing the weekly tag (I think this is allowed and equivalent to removing and pushing a new version), if that does not upset users (pullers) too much. I guess people will be fine with one tag moving every week.

But can we agree on annotated tags where the message changes with the date, as I described in my original suggestion?

Contributor

hermunn commented Oct 17, 2017

I am fine with updating and force pushing the weekly tag (I think this is allowed and equivalent to removing and pushing a new version), if that does not upset users (pullers) too much. I guess people will be fine with one tag moving every week.

But can we agree on annotated tags where the message changes with the date, as I described in my original suggestion?

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 17, 2017

Member

I disagree, because according to the manual:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

Member

Dridi commented Oct 17, 2017

I disagree, because according to the manual:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

@hermunn

This comment has been minimized.

Show comment
Hide comment
@hermunn

hermunn Oct 17, 2017

Contributor

Ok, so non-annotated tags it is, unless someone else objects.

Contributor

hermunn commented Oct 17, 2017

Ok, so non-annotated tags it is, unless someone else objects.

@fgsch

This comment has been minimized.

Show comment
Hide comment
@fgsch

fgsch Oct 17, 2017

Member

Since I was not present during the bugwash I'd like to know why we need to tag at all?
Do we want to release from a specific revision?

PS: tags can be moved. You don't need to remove and re-add them.

Member

fgsch commented Oct 17, 2017

Since I was not present during the bugwash I'd like to know why we need to tag at all?
Do we want to release from a specific revision?

PS: tags can be moved. You don't need to remove and re-add them.

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 17, 2017

Member

During the Monday bugwash, the varnish core developers discuss if the current master should be released as a weekly package.

Basically we want to skip weeks when master contains an incomplete feature, the agreement on incompleteness being subject to bugwash discussions. Weekly builds should be in a decent shape.

Member

Dridi commented Oct 17, 2017

During the Monday bugwash, the varnish core developers discuss if the current master should be released as a weekly package.

Basically we want to skip weeks when master contains an incomplete feature, the agreement on incompleteness being subject to bugwash discussions. Weekly builds should be in a decent shape.

@fgsch

This comment has been minimized.

Show comment
Hide comment
@fgsch

fgsch Oct 18, 2017

Member

@Dridi thanks for the clarification.

Part of me really wonders how many times we'll not create such tag and/or if it's worth having this whole process on demand (as opposed to just create a weekly package) but nevermind.

Any thoughts about updating from say package from week 1 to week 6 (i.e. correct naming/versioning)? Or this is not in scope?

Member

fgsch commented Oct 18, 2017

@Dridi thanks for the clarification.

Part of me really wonders how many times we'll not create such tag and/or if it's worth having this whole process on demand (as opposed to just create a weekly package) but nevermind.

Any thoughts about updating from say package from week 1 to week 6 (i.e. correct naming/versioning)? Or this is not in scope?

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 18, 2017

Would it be a viable solution to just build the package on a set time every week (let's say before the bugwash), and then decide on publishing said package or not?

denisbr commented Oct 18, 2017

Would it be a viable solution to just build the package on a set time every week (let's say before the bugwash), and then decide on publishing said package or not?

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 24, 2017

Working on the jenkins side of things atm.

denisbr commented Oct 24, 2017

Working on the jenkins side of things atm.

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 24, 2017

@Dridi / @fgsch / @bsdphk / @hermunn Any of you care to opine on what the versions for these weekly packages should be?
Some alternatives I can think of:

  • varnish-20171024
  • varnish-5.2.0-20171024
  • varnish-weekly-20171024

Not sure how important this is, but could impact user experience wrt package manager fiddling.

denisbr commented Oct 24, 2017

@Dridi / @fgsch / @bsdphk / @hermunn Any of you care to opine on what the versions for these weekly packages should be?
Some alternatives I can think of:

  • varnish-20171024
  • varnish-5.2.0-20171024
  • varnish-weekly-20171024

Not sure how important this is, but could impact user experience wrt package manager fiddling.

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 24, 2017

Member

Since the version in configure.ac is "trunk" I'd go for an NVR of varnish-trunk-20171024.

Member

Dridi commented Oct 24, 2017

Since the version in configure.ac is "trunk" I'd go for an NVR of varnish-trunk-20171024.

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 24, 2017

@Dridi sounds fine by me, the version bit would be "trunk-YYYYMMDD" then?

denisbr commented Oct 24, 2017

@Dridi sounds fine by me, the version bit would be "trunk-YYYYMMDD" then?

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 24, 2017

Member

Sorry, NVR stands for "name version release", so that would be:

  • name: varnish
  • version: trunk
  • release: YYYYMMDD

I don't think we can have a dash in the version number with either RPM or DPKG.

Member

Dridi commented Oct 24, 2017

Sorry, NVR stands for "name version release", so that would be:

  • name: varnish
  • version: trunk
  • release: YYYYMMDD

I don't think we can have a dash in the version number with either RPM or DPKG.

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 24, 2017

@Dridi parsechangelog/debian: warning: debian/changelog(l1): version 'trunk-20171024' is invalid: version number does not start with digit
So for debian trunk cannot be the version, it can be a suffix.

denisbr commented Oct 24, 2017

@Dridi parsechangelog/debian: warning: debian/changelog(l1): version 'trunk-20171024' is invalid: version number does not start with digit
So for debian trunk cannot be the version, it can be a suffix.

@denisbr

This comment has been minimized.

Show comment
Hide comment
@denisbr

denisbr Oct 26, 2017

No one wants to paint this shed then?
We need to decide on a (debian-deb-compatible) versioning scheme before the weekend, so that we get a first proper weekly build on monday.

denisbr commented Oct 26, 2017

No one wants to paint this shed then?
We need to decide on a (debian-deb-compatible) versioning scheme before the weekend, so that we get a first proper weekly build on monday.

@Dridi

This comment has been minimized.

Show comment
Hide comment
@Dridi

Dridi Oct 26, 2017

Member
  • name: varnish
  • version: YYYYMMDD
  • release: trunk
Member

Dridi commented Oct 26, 2017

  • name: varnish
  • version: YYYYMMDD
  • release: trunk
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment