Skip to content
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
Closed

Weekly packages not implemented yet #2463

hermunn opened this issue Oct 16, 2017 · 20 comments

Comments

@hermunn
Copy link
Member

@hermunn 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.

@bsdphk
Copy link
Contributor

@bsdphk bsdphk commented Oct 16, 2017

Looks good to me.

@fgsch
Copy link
Member

@fgsch 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
Copy link
Member

@Dridi 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
Copy link
Member Author

@hermunn 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
Copy link
Member

@Dridi 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=need bugwash label Oct 16, 2017
@hermunn
Copy link
Member Author

@hermunn 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
Copy link
Member

@Dridi 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
Copy link
Member Author

@hermunn hermunn commented Oct 17, 2017

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

@fgsch
Copy link
Member

@fgsch 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
Copy link
Member

@Dridi 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
Copy link
Member

@fgsch 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
Copy link

@denisbr 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
Copy link

@denisbr denisbr commented Oct 24, 2017

Working on the jenkins side of things atm.

@denisbr
Copy link

@denisbr 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
Copy link
Member

@Dridi Dridi commented Oct 24, 2017

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

@denisbr
Copy link

@denisbr denisbr commented Oct 24, 2017

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

@Dridi
Copy link
Member

@Dridi 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
Copy link

@denisbr 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
Copy link

@denisbr 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
Copy link
Member

@Dridi 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.